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(57) ABSTRACT 

A distributed flow control system and method for GPRS 
networks to control and regulate data flow between multiple 
sources and a single destination within a GPRS network. 
The present system and method ensures the departing traffic 
from all of the sources conforms to the peak and average rate 
requirements that have been set forth by the BSS/PCU. A 
leaky bucket flow control mechanism is used at each respec- 
tive one of the multiple sources for controlling flow of data 
from each respective source to the single destination. A 
maximum bucket size of a leaky bucket and a bucket leak 
rate are defined for each leaky bucket flow control mecha- 
nism. A multiplier (L) is estimated and determined for each 
respective source based on recent data arrival behaviors of 
the multiple sources. When a frame of the data is sent from 
the respective source to the single destination, a number of 
bytes equal to the size of the transmitted frame times the 
multiplier L is added to the leaky bucket. 
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DISTRIBUTED FLOW CONTROL SYSTEM 
AND METHOD FOR GPRS NETWORKS 
BASED ON LEAKY BUCKETS 



BACKGROUND OF THE INVENTION 

1. Technical Field 

The present invention relates in general to a distributed 
flow control system and method for General Packet Radio 
Service (GPRS) networks and in particular to a system and 
method for adapting a leaky bucket mechanism to a system 
having multiple traffic sources wherein the combined traffic 
from all sources must satisfy a single set of peak and average 
rate requirements. 

2. Description of the Related Art 

Wireless communication technologies require the use of 
various defined standards such as for voice and data com- 
munications. General Packet Radio Service (GPRS) is a 
relatively newer version standard that has been established 
for wireless data communications in Europe, and GPRS is 
able to be used anywhere in the world. A general prior art 
diagram of the topology of a GPRS network 10 is shown in 
FIG. 1. The GPRS network 10 generally comprises a number 
of nodes. The GPRS network 10 comprises a mobile switch- 
ing center (MSC), a visitor location register (VLR) 12, a 
home location register (HLR), an authentication center 
(AuC) 14, a gateway GPRS support node (GGSN) 20, a 
serving GPRS support node (SGSN) 24, a base station 
system (BSS) having an antenna 30, and a packet control 
unit (PCU) 28. The MSC/VLR provides voice communica- 
tions for wireless or cellular telephones. The MSC/VLR 12 
is in direct communications with the HLR/AuC 14, the 
SGSN 24, and the BSS/PCU 28. The HLR/ AuC 14 is in 
direct communications with SGSN 24 and GGSN 20. 

The GPRS network 10 is configured to support interfaces 
to and from outside packet data networks. FIG. 1 shows that 
the GGSN 20 is coupled to and in communications with 
outside packet data networks that support the internet pro- 
tocol (IP) 16 or the X.25 protocol 18. In FIG. 1, data packets 
come in from the outside network (i.e. IP 16 or X.25 
networks 18) to the GGSN 20, then to the SGSN 24, and 
then to the BSS/PCU 28. Thus, two way communications 
exist between the BSS/PCU 28 and the SGSN 24, the GGSN 
20, and the outside network(s). One problem that exists for 
the data packet coming from the GGSN 20 (or outside) to the 
SGSN 24 and then to the BSS/PCU 28 is that the packet 
control unit (PCU) may have limited memory space. Along 
queue of incoming data may exist at the PCU, and the PCU 
may not be able to receive anymore data or information from 
the SGSN 24. Therefore, a method for regulating traffic flow 
from the SGSN to the PCU is necessary. 

FIG. 4 is a prior art block diagram of the protocol stack 
55 between the BSS/PCU stack 56 for the BSS/PCU 28 and 
the SGSN stack 66 for the SGSN 24 in a GPRS network 10. 
The BSS/PCU stack 56 comprises a relay 58, a Base Station 
System GPRS protocol (BSSGP) layer 60, a frame relay 
layer 62, and a physical layer 64. The SGSN stack 66 
comprises a relay 66, a SNDCP layer 70, a Logical Link 
Control (LLC) layer 72, a BSSGP layer 74, a frame relay 
layer 76, and a physical layer 78. According to the GPRS 
standards, a frame relay network 63 couples the BSS/PCU 
28 to the SGSN 24. In the BSS/PCU slack 56, BSSGP layer 
60 is located immediately above the frame relay layer 62. 
The operations of the BSSGP layer 60 include flow control 
and transmission of LLC frame 39 or data packet frame 
related information, such as routing and QoS requirements, 
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between the SGSN 24 and the BSS/PCU 28. The data 
streams transmitted from the SGSN 24 to a cell is grouped 
together to form a BSSGP virtual circuit (BVC). Flow 
control between the SGSN 24 and the BSS/PCU 28 is 
performed both on per BVC and per mobile station basis. 

FIG. 2 shows a prior art diagram of the flow control 
between the SGSN 24 and the BSS/PCU 28. Flow control 
parameters 32 are programmed and established from the 
BSS/PCU 28. These flow control parameters 32 are directed 
from the BSS/PCU 28 to the SGSN 24 to control and 
regulate the flow of data from the SGSN 24 to the BSS/PCU 
28. Thus, regulated data flow exists from the SGSN 24 to the 
BSS/PCU 28. The flow control mechanism implemented _at 
the SGSN 24" is based on a leaky bucket flow control 
mechanism. The flow control parameters established by the 
BSS/PCU 28 are used to dimension the leaky bucket mecha- 
nism implemented at the SGSN 24. 

The leaky bucket flow control mechanism is a simple and 
effective system and method for regulating and controlling 
traffic flow. Each leaky bucket is dimensioned by two 
parameters: leak rate (R) and bucket size (maximum bucket 
size B max ). These parameters together control the peak and 
the average rates of traffic departure from a traffic source. 
The leaky bucket flow control mechanism regulates the 
output bandwidth allocation to a traffic source such that 
traffic departing from the controlled source does not exceed 
the specified mean and peak rate values. The basic concept 
of this mechanism is to associate a bucket 40 with a traffic 
source at the SGSN 24 (see FIG. 3). The bucket 40 has a 
finite number of bytes in size (i.e. maximum bucket size 
B max ). When the traffic source at the SGSN 24 transmits 
traffic to the output link 80, an equivalent number of bytes 
must be put into the bucket 40. If the bucket 40 is full, 
transmission is not allowed. The available data 39 is either 
queued in the buffer 38 or discarded. Consequently, the 
traffic source at the SGSN 24 is not able to transmit more 
data 39 than the available capacity of the bucket 40. At the 
same time, the bucket 40 "leaks"(i.e. the bucket level drops) 
at a given leak rate R such that the data departure is not 
totally confined to the finite bucket size. Based on the leaky 
bucket mechanism, the mean departure rate of the traffic 
source at the SGSN 24 cannot exceed the bucket leak rate R. 
At any time instant, the traffic source at the SGSN 24 is not 
able to send out more data 39 than the bucket size B mar . 

An application of the leaky bucket flow control mecha- 
nism 36 (see FIG. 3) is found in GPRS as specified in the 
European Telecommunications Standards Institute (ETSI) 
Global System for Mobile Communications (GSM) phase 
2+ standards [1]. GPRS is the packet data extension of the 
circuit based GSM wireless communication standard. 
Details and applications of these standards and specifica- 
tions are disclosed in ETSI, "Digital Cellular Telecommu- 
nications System (phase 2+); General Packet Radio Service 
(GPRS); Service Description; Stage 2," ETSI GSM 03.60, 
Version 6.1.1, August 1998. These standards, specifications, 
and publications are incorporated by reference herein. Refer- 
ring to FIG. 1 and as stated earlier, the GGSN node 20 is the 
interface between the GPRS network and the outside net- 
works 16 or 18. The GGSN 20 is responsible for forwarding 
data packets to the appropriate SGSN 24 and to provide 
mobility, security, and billing related operations. The SGSN 
24 is responsible for the buffering and delivery of packet 
data and the handling of GPRS related signaling messages 
for subscribers residing in its assigned area. Each SGSN 24 
is connected to one or more BSS/PCU 28. The BSS/PCU 28 
is responsible for interfacing with the mobile station or 
terminal 27 with antenna 29 through the GPRS air interface 
protocol. 
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FIG. 3 shows a prior art diagram of the leaky bucket flow interface cards or SGSNs 24 adhere to the leaky bucket 

control mechanism 36. As a logical link control (LLC) frame parameters as provided by the BSS/PCU 28. 

of data 39 is forwarded from the data buffer 38 of the SGSN One simple solution would be to implement a leaky 

24 to the BSS/PCU 28 via a BSSGP virtual circuit. A number bucket mechanism 36 at each BVC terminating point, 

of bytes equal to the length of the LLC frame must be placed 5 However, since the BSS/PCU 28 is limited to providing only 

in the bucket 40. In other words, the same amount of data 39 one set of leaky bucket parameters for controlling data flow, 

that has been forwarded from the SGSN 24 to the BSS/PCU mc issue becomes how to dimension all of the leaky buckets 

28 needs to be placed into the bucket 40. The data 39 35 us j ng on i y one 0 f parameters to provide flow control 

collected in the bucket 40 leaks at the leak rate (R) 45. The 0 f data. Therefore, a first simple solution to the multiple 

data 39 leaking from the bucket 40 operates to control the 10 leaky bucket dimensioning problem is to dimension all of 

rate of data flow from the SGSN 24 to the BSS/PCU 28 by the leaky buckets to the same set of parameters, that is, 

requiring that a sufficient amount of space (equal to the size dimension all leaky buckets using the same bucket size and 

of the next LLC frame to bejransmitted) in the leaky bucket leak rate.. A second solution would be to have the leak rate 

40'needs to exist before the SGSN 24 can further send data divided among all of the leaky buckets and use the same 

to the BSS/PCU 28. The level of the bucket 40 needs to drop 15 bucket size for all leaky buckets. A third solution would be 

(i.e. "leak") below some level or amount before a next LLC to have the bucket size divided among all leaky buckets and 

frame 39 or data packet can be sent from the SGSN 24 to the use the same leak rate for all leaky buckets. However, all of 

BSS/PCU 28. If the bucket 40 is full or would overflow if these solutions or attempted solutions either fail to enforce 

a next LLC frame 39 is sent, then the next LLC frame 39 is the required peak and average rates (i.e. first solution failure) 

delayed. In other words, a next LLC frame 39 or data frame 20 0 r are overly restrictive such that the allowable peak and 

is forwarded from the SGSN 24 to the BSS/PCU 28 via a average rates cannot be achieved (i.e. second and third 

BSSGP virtual circuit only if the length (L) of the next LLC solutions failures). 

frame 39 is less than or equal to the difference between the Another solution for ensuring peak and average rates 

maximum bucket size (B max ) 43 and the current bucket level ^ouid De t0 pr0 vide a centralized leaky bucket mechanism 

(B cur ) 47, or otherwise, the next LLC frame 39 is delayed. 25 mat regu lates the data traffic from all of the individual 

According to the GPRS standards, the leaky bucket flow routers. The centralized leaky bucket mechanism would be 

control mechanism 36 is used to regulate traffic flow through provided by adding another box or hardware that collects 

a BVC from the SGSN 24 to the BSS/PCU 28. A feedback data from all of the individual routers. However, the adding 

control scheme is then employed to set up the parameters of of an additional box or hardware is not desired due to space, 

the leaky bucket at the SGSN 24. According to this method, 30 cost, and other such issues that arise from utilizing addi- 

each BSS/PCU 28 periodically sends to the SGSN 24 the tional hardware. 

leaky bucket parameter for each BVC supported by the It would therefore be advantageous and desirable to 

BSS/PCU 28. The leaky bucket parameters include the provide a distributed flow control system and method for 

maximum bucket size and the leak rate, which are deter- GPRS networks to control and regulate data flow between 

mined based on the current congestion condition at the 35 multiple sources exist at the SGSN side of the GPRS 

BSS/PCU 28 and the behavior of the air channels. The leaky network and a single destination at the BSS/PCU side of the 

bucket mechanism implemented at the SGSN 24 then con- GPRS netW ork. It would also be advantageous and desirable 

trols the departing traffic of the BVC based on these param- to provide such a distributed flow control system and 

eters. FIG. 3 shows various components involved in the me thod for GPRS networks to ensure the total departing 

BVC flow control 40 traffic from all of the sources conforms to the peak and 

A main problem arises when multiple sources belonging average rate requirements that have been set forth by the 

to the same BVC exist at the SGSN side of the GPRS BSS/PCU. It would further be advantageous and desirable to 

network 10. The difficulty arises when the leaky bucket flow provide such a distributed flow control system and method 

control mechanism 36 is adapted to the situation where f or GPRS networks that dimension all of the leaky bucket 

multiple sources exist at the SGSN side of the GPRS 45 mechanisms using only one set of parameters to provide 

network 10. For example, a distributed network architecture flow control of data traffic. It would still further be advan- 

37 is shown in FIG. 5. The distributed network architecture tageous and desirable to provide such a distributed flow 

37 shows data transferred between a SGSN 24 having within control system and method for GPRS networks that avoids 

it multiple source servers (i.e. serverl 42, server2 44, . . . using an additional box or hardware for being able to 

servern 46) in communication with routers or routing boxes 50 implement the leaky bucket flow control mechanism when 

(i.e. router 148. .. router k 50). The routers, in turn, are in multiple sources exist at the SGSN side of the GPRS 

communication with the frame relay 26 wherein the frame network. 

relay 26 is a public data network (which is similar to the ™,ww ™ , k r, ^»™^. T 

Internet network). The frame relay 26, in turn, is in com- SUMMARY OF THE INVENTION 

munication with the single destination BSS/PCU 28. FIG. 5 55 11 is therefore one object of the present invention to 

shows the problem from the configuration where the mul- provide a distributed flow control system and method for 

tiple sources are multiple routers within the SGSN 24. GPRS networks to control and regulate data flow between 

However, the problem is not limited to multiple sources that multiple sources exist at the SGSN side of the GPRS 

are multiple routers. The multiple sources may be multiple network and a single destination at the BSS/PCU side of the 

source servers, multiple SGSNs 24, and/or any other type(s) 60 GPRS network. 

of multiple source(s) in any systems other than GPRS. It is another object of the present invention to provide 

In other words, the setup in FIG. 5 is where a BVC is split such a distributed flow control system and method for GPRS 

across at multiple hardware interface cards or multiple networks to ensure the total departing traffic from all of the 

SGSNs 24. The setup for this type of hardware/network sources conforms to the peak and average rate requirements 

architecture is preferable since it achieves higher reliability 65 that have been set forth by the BSS/PCU. 

and enhances nodal or network capacity. Thus, it is neces- It is a further object of the present invention to provide 

sary to ensure that the total traffic entering the BVC from all such a distributed flow control system and method for GPRS 
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networks that dimension and factor all of the leaky bucket 
mechanisms using only one set of parameters to provide 
flow control of data. 

It is still a further object of the present invention to 
provide such a distributed flow control system and method 5 
for GPRS networks that avoids using an additional box or 
hardware for being able to implement the leaky bucket flow 
control mechanism when multiple sources exist at the SGSN 
side of the GPRS network. 

The foregoing objects are achieved as is now described. 10 
A distributed flow control system and method for GPRS 
networks to control and regulate data flow between multiple 
sources and a -single destination within a GPRS-network. 
The present system and method ensures the departing traffic 
from all of the sources conforms to the peak and average rate 15 
requirements that have been set forth by the BSS/PCU. A 
leaky bucket flow control mechanism is used at each respec- 
tive one of the multiple sources for controlling flow of data 
from each respective source to the single destination. A 
maximum bucket size of a leaky bucket and a bucket leak 20 
rate are defined for each leaky bucket flow control mecha- 
nism. A multiplier (L) is estimated and determined for each 
respective source based on recent data arrival behaviors of 
the multiple sources. When a frame of the data is sent from 
the respective source to the single destination, a number of 25 
bytes equal to the size of the transmitted frame times the 
multiplier L is added to the leaky bucket. An additional 
frame of data is allowed to be sent from the respective 
source to the single destination if transmission of the data 
frame will not result in overflow of the leaky bucket. An 30 
additional frame of data is prohibited from being sent from 
the respective source to the single destination when trans- 
mission of the data frame will result in the overflow of the 
leaky bucket. 

The above as well as additional objects, features, and 35 
advantages of the present invention will become apparent in 
the following detailed written description. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The novel features believed characteristic of the invention 40 
are set forth in the appended claims. The invention itself 
however, as well as a preferred mode of use, further objects 
and advantages thereof, will best be understood by reference 
to the following detailed description of an illustrative 
embodiment when read in conjunction with the accompa- 45 
nying drawings, wherein: 

FIG. 1 is a prior art block diagram of a GPRS network; 

FIG. 2 is a prior art block diagram illustrating PCU-SGSN 
flow control for a GPRS network; 

FIG. 3 is a prior art block diagram illustrating leaky 50 
bucket flow control for a GPRS network; 

FIG. 4 is a prior art block diagram of a protocol stack 
between a BSS/PCU and a SGSN for the GPRS network; 

FIG. 5 is a prior art diagram illustrating the problems 55 
associated with a distributed network architecture with mul- 
tiple sources on the SGSN side of a GPRS network; 

FIG. 6 is a block diagram illustrating the present invention 
distributed leaky bucket system and method for a GPRS 
network; 60 

FIG. 7 is a diagram that compares a single leaky bucket 
model to the present invention distributed leaky bucket 
model; 

FIG. 8 is a block diagram that illustrates periodic bucket 
synchronization for the present invention; 65 

FIG. 9 is a flow chart of the centralized or master/slave 
synchronization procedure for the present invention; 
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FIG. 10 is a flow chart for the implementation of a regular, 
prior art leaky bucket algorithm; and 

FIG. 11 is a flow chart for the implementation of a 
distributed leaky bucket algorithm for the present invention. 

DETAILED DESCRIPTION OF ILLUSTRATIVE 
EMBODIMENT 

The present invention is a distributed flow control system 
and method for GPRS networks to control and regulate data 
flow between multiple sources exist at the SGSN side of the 
GPRS network and a single destination at the BSS/PCU side 
of the GPRS network. The present distributed flow '.control, 
system and method for GPRS networks ensures the depart- 
ing traffic from all of the sources conforms to the peak and 
average rate requirements that have been set forth by the 
BSS/PCU. The present distributed flow control system and 
method for GPRS networks dimension all of the leaky 
bucket mechanisms using only one set of leaky bucket 
parameters to control flow of data. The present distributed 
flow control system and method for GPRS networks avoids 
the use of an additional box or hardware for being able to 
implement the leaky bucket flow control mechanism when 
multiple sources exist at the SGSN side of the GPRS 
network. 

The present distributed flow control mechanism 52 
ensures that the combined departure traffic 83 from the 
traffic sources (i.e. from router 1 48, router k 50) satisfies one 
set of leaky bucket parameters. With reference now to the 
figures and in particular with reference to FIG. 6, the 
architecture of the present distributed flow control mecha- 
nism 52 is shown. The leaky bucket algorithm that was 
discussed earlier for prior art FIG. 3 is implemented and 
executed at each traffic source (i.e. router 1 48 to router k 50) 
or at each interface card. Each interface card is referred to 
as a leaky bucket controller (LBC). The same leaky bucket 
parameters exist at each traffic source. These parameters are 
the maximum bucket size (B max ) and the bucket leak rate 
(R). For the present invention, "k" is defined as the source 
k while "j" is defined as the time interval j. Each byte of data 
that a traffic source router k 50 transmits to the outgoing link 
81 during time interval j, the traffic source must place L kj 
bytes into its leaky bucket 40 of its LBC where L kj - reflects 
the estimated total departure traffic (measured in bytes) from 
all of the traffic sources (see FIG. 6) for each byte sent by 
router k. With reference now to the FIGS, and in particular 
with reference to FIG. 7, the prior art single leaky bucket 
mechanism 36 only places the same amount of frame size 
(FS) bytes transmitted from the traffic source to the outgoing 
link into the leaky bucket 40 in the LBC while the present 
distributed leaky bucket mechanism 52 places L kJ bytes into 
the leaky bucket 40 at the LBC of the traffic source. Wherein 
the Lfij bytes reflect the transmitted data from the traffic 
source and from all other traffic sources. For example, if it 
is estimated that for every byte transmitted by the traffic 
source k, during time interval j another n bytes will be 
transmitted by the other sources, then the value of L^ should 
be set to n+1 bytes. 

The present distributed flow control system 52 and 
method for a GPRS network 10 for controlling flow of data 
between multiple sources and a single destination within the 
GPRS network generally involves the following. A leaky 
bucket flow control mechanism 53 is used at each respective 
one of the multiple sources 48, 50, etc. for controlling the 
flow of the data 39 from each respective source (i.e. source 
48, 50, etc.) to the single destination 28. A maximum bucket 
size B max of a leaky bucket 40 and a bucket leak rate R are 
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defined for each leaky bucket flow control mechanism 53. A The centralized or master/slave method may suffer from 
multiplier h kJ . 39 is estimated and determined for each reliability problems, particularly in the situation where an 
respective source k (where k=l,2 . . . ) 48, 50, etc. during error or failure occurs at the master leaky bucket 40. 
time interval j based on arrival and queuing behaviors of the Therefore, special safeguards must be put into place to 
multiple sources 48, 50, etc. The number of bytes equal to 5 ensure continued operations if the master leaky bucket 40 
L k j is added into the leaky bucket k 40 when a byte of the fails. The fully distributed method does not require central - 
data 39 is sent from the respective source k 48 or 50 to the ized coordination. In the fully distributed method, each 
single destination 28 during time interval j. An additional leaky bucket 40 broadcasts the estimated traffic availability 
frame of data 39 is allowed to be sent from the respective to all leaky buckets 40 at the end of each synchronization or 
source 48 or 50 to the single destination 28 when the 10 time interval For example, the estimated traffic availability 
respective leaky bucket 40 has sufficient empty space to amount for the next time interval is sent from the leaky 
store a number of bytes equal to the size of the data frame bucket 40 t0 each other leakv ticket 40. The traffic avail- 
multiplied by L w . An additional frame of data 39 is pro- ability values of all leaky buckets are totaled and determined 
hibited from being-sent from the respective source 48 or 50 at ^ ^aky bucket 40. However, the fully distributed 
to the single destination 28 when there is not sufficient 15 me ^ hod mav ^"f relatively high volume of signaling 
emptyspaceintheleakybuckettostorethenumberofbytes traffic among the leaky buckets 40^ Regardless of the 
equal to the size of the data frame times selected method, when a leaky bucket 40 receives the traffic 
4 . r ... * . i . h- availability information, it will use this information to 
At the end of each time interval, the traffic availability . 4 . J T . e , . t . 4 , . . 

. . . ao en . c update the value for use dunng the next synchronization 

amount is estimated for each traffic source 48, 50, etc. for a q j. t ^ me j nte pjf a j 

next time interval. The traffic availability amounts for each 20 . , . 

of the traffic sources 48, 50, etc. are totaled together to A number of different ways to estimate traffic availability 

provide a total traffic availability amount for all of the exists fi ^ P rese f nt mventl0n 15 ° ot in an y ™? ^ited to the 

multiple sources 48, 50, etc. The total traffic availability s P ecific wavs of ^mating traffic availability d isclosed in 

amount is distributed to the leaky bucket 40 associated with this specification, and any suitable way or method for 

each source 48, 50, etc. 2S es,imatin S traffic availability may be used. The present 

, , r 1 r r iL algorithm estimates the traffic availability based on two 

In order to accurately estimate the value 01 Lw, the 0 lN , . , t . , c 

, . parameters: 1) the queue length at the end of the present 

present distributed now control mechanism 52 utilizes a r . /. . . , , 0 ^ fU . J\ «= 

y ™_ , . , synchronization or time mterval and 2) the expected traffic 

synchronization procedure. The synchronization procedure . . , . t . . .. r . . . 

J . ■ <- .,, /1 An r arrival during the next synchronization or time interval, 

periodically informs each leaky bucket 40 tor each tratnc A , ° . ' . 

source 48, 50, etc. or LBC of the traffic availability, during 30 J A data f f ffic arr ' Val ™ Unt for a P rc ^ nt Ume 1 ? tervaI 15 

the next synchronization interval at the other source(s) every determined for each traffic source 48, 50, etc., and a queue 

T seconds This information is then used for the estimation length at the end of the present Ume mterval !s determined 

of the L* , This procedure allows each leaky bucket 40 to at ^ b ucket 4 ? for u each *»ircc 48, 50, etc The data 

account for the departure behavior from its traffic source 48, ^ c ° unt for < h ° P resen « Ume ! n,erva the , 

50, etc. and LBC and for all of the other traffic sources 48, 35 ( ' ueu ? l6 , n & th at lhe end ° f 1 the pre ^ nt Um ? I"*™ 1 are uwid 

50, etc. and LBCs. The procedure provides each leaky 10 calculate an expected data traffic availability for a next 

bucket 40 with up-to-date traffic availability information at Um i mte ™' f ?' eac f h sourcc 5 ?' ctc : 11,6 peeled data 

the other traffic sources and allows each traffic source to * affic availability for the next time mterval is ; used to 

accurately regulate its departure traffic such that the com- determine the multiplier L„ for each source 48, 50, etc. 

bined departure traffic from all sources does not exceed the 40 ^ muilr P ll6r k, for a so™"* K ** e q ual 10 an lnflmte 

maximum allowed values. value wben the expected data traffic availability for the next 

t, . . ,. _ . . • i„„,„„,„j l.. time interval for that particular source equals zero. This 

The synchronization procedure may be implemented by .-, , - ,c rJ r • 

many methods including: 1) a centralized or master/slave ^"PB" ^ 50 ! hat anyaddiuonal frame of data from that 

method and 2) a fully distributed method. The centralized P artI . cular S0 F urc f 15 P roh ! blted &om bemg sent to the single 

.1 1 . ' . , 1 . p „ A nf tUfl u„„u^ * c destination for the next time interval. The multiplier L tf for 

method requires the designation of one of the leaky buckets 45 , , , j . *■' «- 

An t . „ f t . i M i„, i An » M a source is set equal to a ratio of a total expected data traffic 

40 as a master while all of the other leaky buckets 40 are ., . i . . _ _ * , , , . , 

! v., ,. f _ fUa n . . n ,. ^ availability for the next time interval for all of the multiple 

slaves. With reference now to the figures and in particular A £ mn , , _ . „. * 

with reference to FIG. 8, the master/slave configuration is s ° urces 48 ' »• etc ' t° expected data traffic availability for 

shown wherein the traffic source router 1 48 as designated ^ next tlme lnterval for the P art,cular source ' 

with the master leaky bucket 40 while the traffic sources 50 An algorithm is provided to illustrate the present system 

router 2 49 and router N 51 are designated as the slave leaky and method for estimating traffic availability. The algorithm 

buckets 40. At the end of each synchronization interval, the assumes lhat M traffic sources exisl - ^ Eor ,his algorithm, 

slave leaky buckets 40 inform the master leaky bucket 40 of each leak y buckel must «> unl ,he number of bytes that arnve 

their estimated traffic availability from their associated traf- during the synchronization interval, and X, v is defined as the 

fic source for the next synchronization or time interval. The 55 value of the counter at the end 0 f ' * e synchronization 

master leaky bucket 40 collects all of the estimated infor- inte ™l- The counter is reset to zero (0) at the beginning of 

mation from the slave leaky buckets 40 and then distributes next synchronization interval. The algorithm further 

the total estimated traffic availability from aU leaky buckets defines % 38 the 1 ueue 'ength of the traffic source 48, 50, 

40 (including the master itself) to each of the slave leaky elc - or LBC i at the end of the synchronization interval j ; X tJ 

buckets 40. For example, a master leaky bucket 40 is <o as lhe total ,raffic at traffic »»«« or 1 d "n°S 

designated, and the traffic availability amount for the next synchronization interval j; a,.^ as the estimated total traffic 

time interval from each leaky bucket 40 associated with a amval at LBC 1 dunn e synchronization interval j+1; and e, v 

source 48, 50, etc. is sent to the master leaky bucket 40. as ,he estimated traffic availability at traffic source or LBC 

These traffic availability values are totaled and determined at 1 durm 8 synchronization mterval j. Where 1 s^m and j £0, 

the master leaky bucket 40, and the total traffic availability 65 me estimated traffic arrival during the next synchronization 

amount is sent from the master leaky bucket 40 to each slave in,erval » according to the following equation AA: 
leaky bucket 40. 
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c, v+1 -o if ;-o. 

a is the smoothing factor, and a value of 0.5 is recom- 
mended. Other values can be used depending on the system 
requirements. The value of e JJ+1 or the estimated traffic 
availability for the next synchronization interval 
(synchronization interval j+1) is estimated at the end of each 
synchronization interval j according to the following equa- 
tion A: 

In determining the e JJ+1 value, the estimated queue 
lengths-e^ are-truncated at a q fA value -.-In-other- words, if 
expected traffic is too high for a particular source, then 
allocation of output bandwidth resources is limited to a 
certain amount instead of allocating so much resources 
based on proportional amounts to that particular source. This 
truncation eliminates the undesirable effect of long queues 
on the performance of the proposed flow control mecha- 
nism. As an example, for a given leak rate L and a bucket 
size B max , the maximum amount of data that is able to depart 
from a traffic source 48, 50, etc. within a synchronization 
interval of T seconds is L/T+B,^. As a result, a traffic 
source 48, 50, etc. with a queue that is longer than L*T+ 
B max should not be given a larger output bandwidth alloca- 
tion during the next synchronization or time interval com- 
pared to another queue with length equal to L*T+B max . For 
the present distributed flow control mechanism, the q rA value 
is obtained according to the following formula C: 

Each leaky bucket i (i.e. leaky bucket 40) calculates its 
estimated traffic availability, e ijV1 value at the end of each 
synchronization interval j and transmits it to the other leaky 
buckets 40 either directly or through a master leaky bucket 
40. Upon receiving all e jV+1 values from the other leaky 
buckets 40, leaky bucket k (where l=Ek^M) generates its 
value according to the following equation B: 

L kJ+l >*M if (2 from M to M of 
^i, ; vi oW if c ^i = °i and 

Zjt^i^Z from i'-l to M of e i ^ u )/e kiiJlhl otherwise. 

L A vl -oo means that the departure or transmission of data 
39 from the traffic source or LBC k is not allowed for the 
next synchronization or time interval 

Thus, L^- is the leaky bucket parameter. For every byte 
that a traffic source sends out to the outgoing link, then L^. 
bytes need to be placed into its leaky bucket 40. If sufficient 
space in the leaky bucket 40 does not exist, then the 
transmission of data 39 from the SGSN 24 to the BSS/PCU 
28 must be delayed until the level of the leaky bucket 40 is 
lowered via leakage to an available space sufficient amount. 
Note that L kJ satisfies the following equation D for all values 
of j: 

(J from Jfc=l to M of 

FIG. 9 shows a flow chart for a centralized or master/slave 
synchronization procedure 82 for the present invention. The 
procedure 82 starts at an end of a synchronization interval at 
block 84. At block 86, each leaky bucket (LB) estimates the 
traffic arrival for the next synchronization interval (i.e. 
determination of a. jV1 from equation above). The procedure 
82 moves to block 88 where each LB records the existing 
queue length (i.e. determination of qjj) Each LB estimates 
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the traffic availability based on the estimated traffic arrival 
and the current queue length (i.e. determination e iV+1 from 
equations A and C above) at block 90. At block 92, each LB 
sends the estimated traffic availability to the master. The 

5 procedure 82 moves to block 94 where the master computes 
the total estimated traffic availability and sends this estimate 
to all of the leaky buckets (LBs) (i.e. determination of 2 
from i=l to M of e /J+1 ). At block 96, each LB uses the 
received total traffic availability value and its own traffic 

to availability to estimate the LB multiplier to be used in the 
next interval. The procedure 82 moves to block 98 where it 
waits for the end of the synchronization interval and loops 
-back to block 84 where the procedure is repeated therefrom, - 
FIG. 10 shows a flow chart for the implementation of a 

is regular, prior art leaky bucket algorithm 100. The algorithm 
100 starts at decision block 102 where it is determined 
whether one or more LLC frame is available in the buffer. If 
such LLC frame is not available, then algorithm 100 con- 
tinues to wait until such LLC frame is available. When such 

20 LLC frame is available, the algorithm 100 moves to block 
104. At block 104, the expected bucket level (B 1 ) if the LLC 
frame is sent is determined. The expected bucket level (B') 
is calculated by taking the maximum of the difference value 
of the current bucket level (B) and the product of the 

25 difference of the current time (T c ) and the time when the last 
LLC frame was sent (T p ) and the leak rate (L) or the zero 
value and adding this determined maximum with the size of 
the LLC frame to be transmitted (K), that is, B'=max 
(B-(T e -Tp)L, 0)+K. At decision block 106, the algorithm 

30 100 determines whether the expected bucket level if the 
LLC frame is sent (B*) is less than or equal to the bucket size 
(B max ). If B' is not less than or equal to B^, then the 
algorithm 100 moves to block 114 where the LLC frame 
transmission is delayed, and the algorithm 100 then loops 

35 back to the decision block 102 to continue therefrom. 
However, if B' is less than or equal to the bucket size (B ma J, 
then at block 108, the current bucket level (B) is set equal 
to the expected bucket level if the LLC frame is sent (B*), 
The algorithm 100 moves to block 110 where the time when 

40 the last LLC frame was sent (T p ) is set equal to the current 
time (TJ. T c is the current time which continuously keeps 
increasing. The algorithm 100 moves to block 112 where the 
LLC frame is sent, and the algorithm 100 loops back to 
decision block 102 to continue therefrom. 

45 FIG. 11 shows a flow chart for the implementation of a 
distributed leaky bucket algorithm 116 for the present inven- 
tion. The algorithm 116 is the same as the algorithm 100 
except for a couple key differences. The blocks 118, 120, 
122, 124, 126, 128, and 130 for algorithm 116 are similar 

50 and respectively parallel the block 102, 104, 106, 108, 110, 
112, and 114 for algorithm 100. However, the algorithm 116 
have subscript i designations in the various blocks while 
algorithm 100 does not have such designations. The sub- 
script i by a variable means that the variable is for leaky 

55 bucket i. Also, the L I(/ is used in the second block 120 for 
algorithm 116 to calculate the expected bucket level if the 
LLC frame is sent (B') as compared with it not being used 
in the second block 104 for algorithm 100. 
The present invention system and method discloses a 

60 leaky bucket flow control system and method for a GPRS 
network 10 for controlling flow of data 39 between multiple 
sources 48, 50, etc. and a single destination 28 within the 
GPRS network 10 is disclosed. A leaky bucket flow control 
mechanism 53 is provided at each of the multiple sources 48, 

65 50, etc. for controlling the flow of the data 39 from each 
source 48, 50, etc. to the single destination. A maximum 
bucket size B,,,^ of a leaky bucket 40 and a bucket leak rate 
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R are defined for each leaky bucket flow control mechanism 
53. A leaky bucket multiplier is estimated and determined 
for each source 48, 50, etc. based on departure behaviors of 
the multiple sources 48, 50, etc. The estimated data avail- 
ability for the next time interval is collected from each leaky 5 
bucket 40 and totaled together to determine a total estimated 
data availability for the next time interval. The total esti- 
mated data availability is communicated to each leaky 
bucket 40 which is then used to calculate the leaky bucket 
multiplier. A number of bytes equal to the multiplier times JQ 
the frame size is added to a leaky bucket 40 when a frame 
of data 39 is sent from the respective source for that leaky 
bucket 40 to the single destination 28. A frame of data 39 is 
.allowed to be.sent from the respective source 48, 50, etc. to 
the single destination 28 if the respective leaky bucket 40 
will not overflow after the transmission of the frame, and a 15 
frame of data 39 is prohibited from being sent from the 
respective source 48, 50, etc. to the single destination 28 if 
the respective leaky bucket 40 will overflow after the 
transmission of the frame. 

The present invention also discloses a distributed flow 20 
control system 52 for a GPRS network 10 for controlling 
flow of data 39 between multiple sources 48, 50, etc. and a 
single destination 28 within the GPRS network 10. The 
system 52 generally comprises a leaky bucket flow control 
mechanism 53 associated with each of the multiple sources 2 $ 
48, 50, etc. for respectively controlling the flow of the data 
39 from each source 48, 50, etc. to the single destination 28. 
The leaky bucket has a maximum bucket size B max and has 
an associated bucket leak rate R at which the data 39 leaks 
from the leaky bucket. The distributed leaky bucket flow 30 
control mechanism 53 estimates and determines a leaky 
bucket multiplier for each source 48, 50, etc. based on 
arrival and queuing behaviors of the multiple sources 48, 50, 
etc. It also adds a number of bytes equal to the multiplier 
times the transmitted frame size into the leaky bucket when 35 
a frame of the data 39 is sent from the respective source 48, 
50, etc. to the single destination 28. The leaky bucket 
mechanism 53 allows an additional frame of data 39 to be 
sent from the respective source 48, 50, etc. to the single 
destination 28 if the respective leaky bucket 40 will not 40 
overflow after the transmission of the frame and prohibits an 
additional frame of data 39 from being sent from the 
respective source 48, 50, etc. to the single destination 28 if 
the respective leaky bucket 40 will overflow after the 
transmission of the frame. 45 

While the invention has been particularly shown and 
described with reference to a preferred embodiment, it will 
be understood by those skilled in the art that various changes 
in form and detail may be made therein without departing 
from the spirit and scope of the invention. 50 

What is claimed is: 

1. A distributed flow control method for controlling flow 
of data between multiple sources and a single destination 
within a GPRS network, said method comprising the steps 

<* 55 
using a leaky bucket flow control mechanism having a 
leaky bucket with a maximum bucket size and a bucket 
leak rate at each respective one of the multiple sources 
for controlling the flow of the data from the multiple 
sources to the single destination, $o 
estimating a traffic availability for the leaky bucket at each 
of the multiple sources for a next time interval based on 
arrival and queuing behaviors of each of the multiple 
sources, 

determining a total traffic availability for the next time 65 
interval by collecting and totaling a traffic availability 
from each of the multiple sources, 
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allowing an additional data frame to be sent to the single 
destination from those of the multiple sources at which 
the leaky bucket will not overflow based on the esti- 
mated traffic availability after sending the additional 
data frame in the next time interval, 
prohibiting an additional data frame from being sent to the 
single destination from those of the multiple sources at 
which the leaky bucket will overflow based on the 
estimated traffic availability after sending the addi- 
tional data frame in the next time interval, and 
at each of those multiple sources sending an additional 
data frame, adding a number of bytes of data to the 
- leaky bucket equal to a size of the additional data frame 
multiplied by a respective leaky bucket multiplier 
greater than 1, wherein the respective leaky bucket 
multiplier of each source is calculated based upon said 
total traffic availability for the next time interval. 

2. The method according to claim 1, and further compris- 
ing: 

communicating the total traffic availability to each of the 

multiple sources, and 
using the total traffic availability to calculate a leaky 
bucket multiplier for the next time interval. 

3. The method according to claim 2, wherein: 
said method further comprises: 

designating a master source among the multiple 
sources, 

sending the traffic availability for the next time interval 
from each of the multiple sources to the master 
source, 

said determining comprises said master source totaling 
the traffic availability for all of the multiple sources, 
and 

said communicating comprises the master source sending 
the total traffic availability to each of the other multiple 
sources. 

4. The method according to claim 2, wherein said deter- 
mining further comprises the steps of: 

sending an individual traffic availability for the next time 
interval from each source to each other of the multiple 
sources, and 

each source among the multiple sources individually 
totaling the individual traffic availabilities to determine 
the total traffic availability of all of the multiple 
sources. 

5. The method according to claim 1, wherein estimating 
a traffic availability comprises: 

recording a traffic arrival amount for a present time 

interval at the leaky bucket, 
recording an existing queue length at the leaky bucket, 
estimating a traffic availability for a next time interval at 
the leaky bucket based on the traffic arrival amount and 
the existing queue length. 

6. A leaky bucket flow control method for controlling flow 
of data between multiple sources and a single destination 
within a GPRS network, said method comprising the steps 
of: 

providing a leaky bucket flow control mechanism at each 
of the multiple sources for controlling the flow of the 
data from the multiple sources to the single destination, 
defining a maximum bucket size of a leaky bucket and a 
bucket leak rate for the leaky bucket flow control 
mechanism of the each of the multiple sources, 
estimating a traffic availability for the leaky bucket at each 
of the multiple sources, 
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collecting and totaling the traffic availability from the 
leaky bucket at each of the multiple sources to deter- 
mine a total estimated traffic availability, 

communicating the total estimated traffic availability to 
the leaky bucket at each of the multiple sources, 

using the total estimated traffic availability and the respec- 
tive traffic availability to determine a leaky bucket 
multiplier for the respective leaky bucket at each of the 
multiple sources, and 

using the leaky bucket multiplier in a next time interval to 
determine whether an additional data frame is to be sent 
from each of the multiple sources to the single desti- 
nation^ the next time interval. 

7. The method according to claim 6, further comprising 
the steps of: 

allowing an additional data frame to be sent to the single 
destination from each of those sources at which the 
respective leaky bucket will not overflow after sending 
the additional data frame in the next time interval, and 

prohibiting the additional data frame from being sent to 
the single destination from each of those sources at 
which the respective leaky bucket will overflow after 
sending the additional data frame in the next time 
interval. 

8. The method according to claim 7, further comprising 
the step of: 

adding a number of bytes equal to the leaky bucket 
multiplier times a size of the additional data frame to 
the leaky bucket at each of the multiple sources when 
the additional data frame is sent from a respective one 
of the multiple sources to the single destination. 

9. A distributed flow control system for controlling flow 
of data between multiple sources and a single destination 
within a GPRS network, said system comprising: 

a respective leaky bucket flow control mechanism at each 
of the multiple sources for controlling the flow of the 
data from the multiple sources to the single destination, 
said leaky bucket flow control mechanism including a 
leaky bucket having a maximum buffer size and an 
associated bucket leak rate at which the data are 
transmitted from the leaky bucket, 

wherein the leaky bucket flow control mechanism at each 
of the multiple sources estimates a leaky bucket mul- 
tiplier for its leaky bucket for a next time interval based 
on arrival and queuing behaviors of all of the multiple 
sources, adds to the leaky bucket a number of bytes 
equal to the leaky bucket multiplier multiplied by a size 
of an additional data frame if the additional data frame 
is sent, allows the additional data frame to be sent to the 
single destination if its leaky bucket will not overflow 
based on the estimated leaky bucket multiplier after 
sending the additional data frame in the next time 
interval, and prohibits the additional data frame from 
being sent to the single destination if its leaky bucket 
buffer will overflow based on the estimated leaky 
bucket multiplier after sending the additional data 
frame in the next time interval. 
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10. The distributed flow control system according to claim 

9, wherein the leaky bucket flow control mechanisms of the 
multiple nodes further estimate a traffic availability for the 
next time interval for each leaky bucket, total the traffic 
availabilities of all of the multiple sources to determine a 
total traffic availability, and distribute the total traffic avail- 
ability to each leaky bucket for use in determining a leaky 
bucket multiplier for the next time interval. 

11. The distributed flow control system according to claim 

10, wherein said leaky bucket flow control mechanisms 
include a master leaky bucket control mechanism that 
receives the traffic availabilities foiMhe next time interval 
from each leaky bucket, that totals the received traffic 
availabilities to determine the total traffic availability, and 
that sends the total traffic availability to each leaky bucket. 

12. The distributed flow control system according to claim 
10, wherein each leaky bucket sends its traffic availability 
for the next time interval to each other leaky bucket and 
wherein each leaky bucket totals traffic availabilities 
received from other leaky buckets to determine the total 
traffic availability. 

13. A distributed leaky bucket flow control method for 
controlling flow of data between multiple sources and a 
single destination within a GPRS network, said method 
comprising the steps of: 

associating a respective one of a plurality of leaky buckets 

with each of the multiple sources, 
determining whether at least one logical link control 

(LLC) frame is available in a buffer associated with a 

particular leaky bucket among the plurality of leaky 

buckets, 

waiting for the at least one LLC frame to be available if 
the at least one LLC frame is not available, 

calculating an expected bucket level based on an assump- 
tion that one of the at least one LLC frame that is 
available were sent to the single destination if the at 
least one LLC frame is available, 

determining whether the expected bucket level is greater 
than a maximum size for the particular leaky bucket, 

delaying transmission of the at least one LLC frame if the 
expected bucket level is greater than the maximum size 
for the particular leaky bucket, 

if the expected bucket level is not greater than the 
maximum size: 

updating a current bucket level of the particular leaky 
bucket with the expected bucket level, 

updating a last LLC frame transmitted time with a 
current time, and 

sending the one of the at least one LLC frame to the 
single destination. 

14. The method according to claim 13, wherein the 
method is a continuous method and the method steps are 
repeated. 
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